Breaking Changes

Breaking Changes for Pronghorn Core 7

Pronghorn-core v7.0.0 contains several changes related to how IAP interacts with the Mongo database. This product notice includes a list of all changes, including ones that might be breaking for custom applications.

Updated Database Module

The database module has been updated to support MongoDB v3.6.

• The 2019.1 IAP release is fully compatible and certified for use of MongoDB v3.6.
• The node mongodb drivers have been updated to use v3.1.13 (see the Mongo Driver Change Log for 3.x), which includes several potentially breaking changes and deprecations, which are outlined below.

MongoDB 3.x Driver Changes

• Removal of API methods such as DB.prototype.authenticate and DB.prototype.logout

  • These removals will only have impact if you are making direct connections to Mongo using the MongoClient supplied with the driver in pronghorn-core.
  • If you have been using the persistence broker, all changes pertinent to authentication and authorization of the database have already been taken care of.

• Deprecation of collection methods. See the MongoDB 3.1 API Collection page for more information on each available and deprecated collection method.

  • count
  • insert
  • dropAllIndexes
  • ensureIndex
  • findAndModify
  • group
  • remove
  • save
  • update

• The methods shown below have changed the data type for the returned insertedIds property.

  • insert (deprecated)
  • insertOne
  • insertMany
  • bulkWrite

Accordingly, if you have existing code that is referencing the insertedIds property, you will need to make updates to check for an object instead of an array of string values. Refer to the following examples.

Example: Old response from insert.

    "result": {
        "ok": 1,
        "n": 1
    },
    "ops": [
        {
           ...properties
        }
    ],
    "insertedCount": 1,
    "insertedIds": [
       "newly_inserted_object_id"
    ]
}

Example: New response from insert (etc)

{
    "result": {
        "ok": 1,
        "n": 1
    },
    "ops": [
        {
           ...properties
        }
    ],
    "insertedCount": 1,
    "insertedIds": {
        "0": "newly_inserted_object_id"
    }
}

All Itential product applications have been updated to remove these deprecated calls, or to take into account updated responses with the new driver. If any of your custom applications use any of the calls listed above, they might need to be updated to be compliant with IAP 2019.* For custom applications that only used the database calls offered by the persistence broker, they will continue work as expected after updating to the 2019.1 IAP release.

Note: The adapter-mongo adapter is scheduled for deprecation and has not been updated with the new MongoDB driver v3.1.13. If you are using adapter-mongo exclusively for your connections, you should not see any observable changes in call behavior. However, you will not be able to use the full feature set of MongoDB version > 3.6 until you have migrated away from adapter-mongo.

Deprecation of Persistence Broker and Adapter-Mongo

The new preferred way for custom applications to access the Mongo server is to create their own connection to the Mongo server and use their own database.

Follow this guide to establish your own database connection using MongoDB: http://mongodb.github.io/node-mongodb-native/3.2/quick-start/quick-start/">MongoDB Quick Start

Since custom apps are no longer required to use MongoDB, any database you wish to use is acceptable. Of note, the Persistence Broker and Adapter-Mongo will be removed in a future release of IAP. This means that custom applications that use the Persistence Broker or adapter-mongo will need to be updated before the environment can be updated to that release (when it occurs).

Itential will continue to work bug fixes for the Persistence Broker and adapter-mongo until both are removed from IAP.

Corrected Workflow Engine Job Variable Validation

Versions of the Workflow Engine prior to the 2019.1.8 maintenance release contained a job variable validation flaw that prevented the user from being prompted for certain required job variables.

We have corrected this issue and now all required job variables must be supplied when a workflow is started, either from the UI or from the startJobWithOptions API.

If your workflows contain either of the following two scenarios, you will need to correct the workflows before promoting this maintenance release to a production environment.

Please note that each scenario outlined below is now being properly validated.

1. The first scenario involves two tasks connected by a failure transition.

   

   The first task registers a job variable when the task errors.

   

   The second task (connected by a failure transition) is attempting to consume the job variable; however, since the task emitted an error instead of a failure, the job variable has never been set.

   

   Previously, the job would have started and failed if this particular transition were reached. Now that the job variable validation has been corrected, the job will not start without the variable provided as input.

   

   To correct this issue, review the transitions between the two tasks and assess the following solutions:

   Transition	Solution
   The transition was erroneously built as a failure transition instead of an error transition.	Change the transition to an error transition.
   The failure transition is correct and the job variable value should be provided by some other task in the workflow.	Identify the task that should provide the job variable value.
   Both the failure transition and the job variable were built correctly.	The job variable value will need to be provided by the initiator of the job.

2. The second scenario involves a task which self-references a job variable in both the input and error screens.

   

   The View Data task is consuming the job variable as input.

   

   The same job variable is produced by the task on the error transition.

   

   If this job variable is not defined anywhere else in the workflow, the validation should now properly fail and prompt the initiator to provide a value for the variable.

   

   To correct this issue, review the workflow for usage of this job variable. Identify the task that is meant to produce a value for the variable.

   If no such task exists, use the newVariable task to provide a default value for the variable.